Route 53

Route53 AWS'in DNS servisidir. Route53'e girmeden önce DNS hakkında kısa bilgi verelim. Önce terminolojiye bakalım daha sonra DNS nasıl çalışır onu inceleyelim.

DNS Terminolojisi

Domain Register: Sizin kullanmak istediğiniz web sitesi adresini kontrol edip daha önce kullanılmayan bir adres ise onu alabileceğiniz bir hizmet sağlayıcısıdır. Route53 ,GoDaddy gibi.

DNS Record: A, AAAA, CNAME, NS, SOA gibi kayıtlardır içeriğine konu içerisinde gireceğiz.

Root Domain: Girdiğimiz web site isimlerinin sonunda görülemeyen kısımdır. Ne işer yaradığı alttaki resim üzerinden anlatılacak.

Top Level Domain(TLD): .com, .net, .gov gibi adresin sonunda gördüğümüz kısım

Second Level Domain(SLD): google.com , example.com gibi adresin TLD öncesi diyebiliriz.

Name Server(NS): Gitmek istediğiniz adresin ip adresini tutan server'lardır. Çözümleme yaparlar.

DNS'in Çalışma Mantığı

Biz ulaşmak istediğimiz bir siteye www.google.com şeklinde ismini girerek ulaşırız ama aslında biz o siteye, sitenin içeriğini saklayan server'ın bir ip bilgisi ile erişiriz. Fakat insanın doğası gereği her girmek istediği sitenin ip numarasını bilmesi zor olacaktır. Bizim için bu girdiğimiz site isminin ip karşılığını döndüren bir hizmete ihtiyacımız var. Bize bu hizmeti sağlayan servise de Domain Name Server kısaca DNS diyoruz. Şimdi arka planda bu işlem nasıl yapılıyor onu inceleyelim.

Yukarıdaki resim üzerinden anlatacağım. Girdiğimiz adreslerin en sonunda görülmeyen bir "." vardır. Buna root domain denir. Root domainin vazifesi TLD(Top Level Domain) listelerini tutmaktır. yani ".com", ".net" gibi TLD leri tutan server'lardır. Sizin girdiğiniz site adresi ".com" ile biterse root domain size ".com" adresilerini tutan server şudur diye cevap döner. Ben example.com adresini arıyorum şeklinde bir istek TLD'ye gider. TLD'de size example.com adresinin tutulduğu SLD(Sub LevelDomain) adresini size döndürür. Siz sonunda girmek istediğiniz adresin ip'sini bilen server'ı bulmuş oluyorsunuz. Son olarak SLD'ye ben www.example.com adesinin ip'sini arıyorum bunun cevabı sizdeymiş dediğinizde size istediğiniz ip dönmüş olur.

Yukarıdaki şekilden özetleyecek olursak. Gitmek istenen adres önce sizin host bilgilerini tutan dosyalarınızdan sorgulanır. Eğer yoksa 1 numara ile gösterilen Local DNS server'a sorulur. Local DNS server'da yoksa 2 numara ile gösterilen şekilde o da root DNS'e sorar. Root DNS server'da ben o adresi bilmem ama .com bilgilerini tutan server adresini vereyim ona sor der. 3 numaralı sorgu ile TLD'ye sorgu gider. O da aynı şekilde ben bilemem ama bende example.com'un ip sini tutan server bilgisi var deyip onu döner. Son 4 numaralı sorguyla SLD'ye sorulur o da istenilen adresin ip bilgisini döner.

Şimdi Route53'e dönelim. Route53 tamamen amazon tarafından yönetilir. DNS kayıtlarını tutar ve kayıtlar üzerinde işlem yapmanıza olanak sağlar. Ayrıca Domain register'dır yani domain name satın alabilirsiniz. Kaynaklarınıza health check yapmanıza olanak sağlar bu sayede sağlıksız sunuculara istek göndermez. Ayrıca senaryolarını göreceğimiz türlü şekillerle kaynaklara load balancing yaptırabilirsiniz.

DNS Records

Bir domain'e trafiği nasıl yönlendireceğinizi tutan kayıtlardır. Her record;

Domain Name

Record Type(A, AAAA, CNAME, vb.)

Vlaue (132.547.658.21)

Routing Policy

TTL(Time to Live) bilgilerini içerir.

Yeri gelmişken TTL değerini burada açıklayalım.

TTL(Time to Live): Atılan sorgu sonucu DNS server IP adresi ile birlikte TTL değeri gönderir. Nedir nu TTL? DNS sunucusuna sorgu atıldıktan sonra belirtilen değer süresince tekrar sorgu atılmaz ön bellekten cevap verilir. DNS sunucu aslında şunu demiş oluyor. İstediğin adresin ip adresi şudur ve sen bana bunu TTL süresi boyunca sorma. IP adresi sık sık değişiyorsa bu değer düşük olmalı, statik web siteleri için ip adresi değişimi çok beklenmiyorsa bu değer yüksek olabilir. Ayrıca TTL süresinin fazla olması Route53'e trafiğin az olmasına bu da düşük ücret anlamına gelir. TTL süresi 60 sn ile 2 gün arasında olabilir.

Şimdi bazı Record Type'lara bakalım;

A : hostname'in IPv4 adresi

AAAA : hostname'in IPv6 adresi

CNAME: farklı bir hostname'in hostname'i. CNAME belirtirken SLD şeklinde yani www.example.com şeklinde girilebilir. example.com şeklinde verilemez.

NS(Name Server): Yetkili DNS sunucularının listesini içerir. Sizin domain adresinizi buradaki sunucular tutarlar.

SOA(Start of Authority): Yönetimsel bilgileri içerir. DNS sunucuları birbirleriyle nasıl haberleşmeli, ne sıklıkla dosya göndermeli gibi temel kayıtlar SOA altında tutulur.

Şimdi de Hosted Zone tiplerini inceleyelim;

Public Hosted Zone: İnternete açık public domain name'lerin kayıtlarının tutulduğu alanlar. Her yerden erişilebilen adreslerin kayıtları tutulur.

Private Hosted Zone: Kendi local'inizde çalıştığınız bir domain belirleyeceğinizde bunu private Hosted Zone'da yapmalısınız. Bir veya daha fazla VPC'den erişilebilecek şekilde yapılabilir. Neden böyle bir ihtiyacımız olabilir? Bir banka düşünün dışarıdaki müşterilerin gördüğü menülerden daha detaylı ekranları olması gerekebilir veya canlıda olan bir uygulamanızın geliştirme aşamaları aynı isimle kendi iç ağınızda yapmanız gerekecektir.

Her hosted zone için aylık 0.50 $ ücretlendirmesi olacaktır.

Domain Register İşlemleri

Şimdi konsola geçelim domain satın alma kısmı ile başlayalım. Arama çubuğuna Route53 yazalım.

Dashboard'da daha önce domain name almadı iseniz işaretli yerleri 0 olarak göreceksiniz. Sol konsoldan Register Domains kısmına tıklayalım.

Karşınıza iki seçenek çıkacak. Başka bir domain register'da bir domain varsa transfer damain ile AWS'e aktarabilirsiniz. Register Domain ile yeni bir domain alabilirsiniz. Register Domain'i seçelim. 3 aşamada işlemi tamamlayacaksınız. 1. aşamada istediğiniz TLD uzantısı ile adresinizin müsait olup olmadığını görebilirsiniz. Fiyatları da görülecek. belirlediğinizde add to cart'a tıklayarak ilerleyelim. 2. aşamada kimlik ve adres bilgilerinizi giriyorsunuz. 3. aşamada kontrol ettikten sonra otomatik her yıl yenilensin mi seçeneği default seçili olduğu için kaldırabilirsiniz. Şartları kabul edip işlemi tamamlayabilirsiniz. Hazır hale gelmesi birkaç saat sürebilir.

Hazır olduktan sonra sol konsolda bulunan Hosted Zone menüsünden public bir zone oluşturulduğunu ve içerisinde sadece NS ve SOA kaydı olduğunu görebilirsiniz.

Şimdi yeni bir kayıt oluşturalım ve oluşturduğumuz kayıt ile browser'dan giriş denemesi yapalım. Uygulama şeklinde yapacağım benimle beraber yapabilirsiniz.

1- Öncelikle public subnet'te SSH ve HTTP portu açık bir EC2 ayağa kaldıralım, SSH ile bağlanıp apache server kuralım(sudo yum install -y httpd). HTML klasörüne gidelim(cd /var/www/html). Bu klasör içine bir index.html yapıştıralım. Yoksa da sıkıntı değil kendi index.html'ini görebiliriz. Son olarak apcahe server'i çalıştıralım(sudo systemctl start httpd , sudo systemctl enable httpd)

2- Yukarıdaki Hosted Zone sayfasına gelelim ve create record'a tıklayalım.

Record name olarak test.devopsandclouds.com girdim. Record kaydını A yani value'sunu ipv4 olarak vercem dedim. Value kısmına da nginx kurulu ec2 public ip sini girdim. TTL değerini anlatmıştım. Routing policy simple olarak kalsın diğerlerine bakacağız.

3- Browser'a test.devopsandclouds.com adresini girelim ve çıktıyı görelim.

Şimdi uzun bir uygulama yapacağız. Burada 3 ec2 ayağa kaldıracağız. Adım adım yapacağız ve routing policy'leri uygulamalı olarak göreceğiz.

1- 3 farklı region'da, aşağıda vereceğim user data'yı kullanarak, public subnet'te SSH ve HTTP portu açık 3 EC2 ayağa kaldıralım. User data ile apache web server kuruyoruz. Hangi ip ve Hangi AZ'den bağlandığımızı görebileceğimiz bir çıktı verecek.

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
EC2_AVAIL_ZONE=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
echo "<h1>Hello World from $(hostname -f) in AZ $EC2_AVAIL_ZONE </h1>" > /var/www/html/index.html

2- Bir adet load balancer oluşturalım herhangi bir region'daki ec2'yu dahil edelim. Load balancer'ın ve oluşturduğumuz ec2'ların public ip'lerini not alalım. Load Balancer'ı ileride alias kaydı oluştururken kullancağız.

3- Bu adımda TTL için bir uygulama yapacağız. Yeni bir kayıt oluşturalım ve A record tipi ile ilk ec2 muzun adresini girelim TTL değeri de 120 sn olsun.

ttl.devopsandclouds.com adresine girdiğimde 120 sn boyunca aynı değeri göreceğim.

120 sn dolmadan kaydı düzenleyelim ve ip adresini diğer ec2 lardan birini seçelim. Sayfayı yenilediğimizde 120 sn dolmadığı için aynı sonuç olduğunu görelim.

120 sn dolduktan sonra yenilediğimizde değiştiğini görelim.

4- Bu adımda CNAME ve ALIAS kayıtları ile ilgili uygulama yapacağız. Öncesinde farklarına kısaca bakalım. CNAME'den bahsetmiştik value olarak başka bir hostname giriyorduk. Bu hostname herhangi bir hostname olabilirdi. Fakat Alias da sadece AWS kaynaklarının hostname'ini girebiliriz. Alias'da TTL değeri girilmez. A ve AAAA her ikisini de destekler. Alias ücretsizdir. Aşağıdaki resimde görülen kaynaklar için Alias kullanılabilir. Son fark olarak CNAME de kayıt bilgisi boş olamaz yani devopsandclouds.com kaydı CNAME ile oluşturulamaz(önüne www gibi isim girilmeli), fakat alias oluşturulabilir. Note: EC2 dahil olmadığı için EC2'nun DNS name'i olmaz.

Konsola geçelim ve bir CNAME oluşturalım.

Kayıt cname.devopsandclouds.com girdim. tip CNAME seçtim ve value kısmına daha önce oluşturduğum load balancer'ın DNS name'ini girdim.

CNAME bizim iş yükümüz hafifletecek bir kayıt türü. Onlarca sub-domain var diyelim ve her birini de xxx.localdevops adresi olan 1.3.5.9 adresine yönlendirdiniz. Oldu da xxx.localdevops adresi değişirse hepsine tek tek ip adresi girmeniz gerekecekti. Bunun yerine xxx.localdevops adresine yönlendirmiş olduğumuzda xxx.localdevops adresi değişse de diğerleri etkilenmeyecek.

Şimdi de alias oluşturalım.

Kayıt adını alias.devopsandclouds.com girdim. Record tipi A olarak bıraktım. Sağ kısımda alias'a tıkladım ve alias menüsü açıldı. İlk olarak target olarak AWS kayanğı tipi olarak ALB seçtim. Takiben region seçtim. En son zaten kendisi o region'da bulunan ALB'yi çıkarttı.

5- Bu bölümde daha önceki bölümlerde default bıraktığımız routing policy'lere bakacağız. 7 tane policy bulunmakta. Simple, Weighted, Failover, Latency based, Geolocation, Multi-Value Answer ve Geoproximity.

a- Routing Policy - Simple

Bir veya birden fazla value girilebilir. Birden fazla girilirse random sonuç döndürür. Health check yapmaz.

Kayıt adı simple.devopsandclouds.com girdim. value olarak 3 ec2 nun da ip'sini girdim. TTL değerini düşük tuttum deneme yapacağım için. Policy olarak da simple seçtim.

Bir süre bekledikten sonra sayfayı yenilediğim zaman diğer ec2'ya bağlandığını gördüm.

Simple'da bu değişim random oldu. Health check aktif değildir.

b- Routing Policy - Weighted

Bu policy tipinde kaynaklarınızın hangi yoğunlukta kullanılacağını ağırlık vererek belirtiyorsunuz. Burada örneğimizde 3 kaynak var ve birazdan ilk kaynak için weight değerini 60, ikinci kaynak için 30, son kaynak için 10 gireceğim. Bu sayede gelen taleplerin %60 ını ilk kaynak, %30 unu ikinci kaynak, %10 unu son kaynak karşılayacak. Ayrıca bu model de health check özelliğini aktif yapabilirsiniz. Son olarak toplam değer 100 olmak zorunda değil oranı bulurken;

((herhangi bir kaynağa verilen ağırlık) / toplam ağırlık) *100 şeklinde trafik yüzdesi bulunabilir. Eğer bir kaynağa trafik gitmesin isterseniz 0 girebilirsiniz. Yeni bir kayıt oluşturalım.

record name olarak weight.devopsandclouds.com girdim. TTL 3 yaptım hızlı deneme yapmak için. policy olarak da Weighted seçtim yukarda belirttiğim oranları verdim.

c- Routing Policy - Latency-based

Bu policy tipinde kaynaklarına erişmek isteyen kullanıcılara kendilerine düşük gecikme ile cevap veren kaynak tarafından dönüş yapılır. En düşük gecikme kendilerine en yakın server olmuş olacaktır. Sizin dünya genelinde ulaşılan bir uygulamanız var Avrupa'da ve Amerika'da kaynakları belirttiniz. Bu durumda Amerika'dan erişmek isteyen müşterilere Amerika'daki server'lar cevap vermiş olacak. Konsoldan girdileri yapalım. 2 kayıt gireceğim record name latency.devopsandclouds.com, birisi us-east-1'da diğeri eu-central-1 de. Ben Türkiye'den istek yaptığımda hangisi cevap verecek göreceğim.

Bana avrupa region'undaki makine cevap verdi. Diyelim ki avrupa'daki makine arızalı ulaşılamıyor bu durumda ne olacak? Health check özelliği sayesinde bu sıkıntıdan kurtulabilirsiniz. Şimdi yeri geldiği için Health check konusunu anlatalım.

Health Check(HC):

Bir kaydınıza ait birden fazla kaynak olduğunda policy'e en uygun kaynak cevap verir. Bu özelliği aktif hale getirdiğinizde en uygun kaynakta bir sıkıntı varsa diğer kaynaklar da cevap verebilir olmuş oluyor.

Sadece public kaynaklar için uygulanabilir. Private Hosted Zone'larda uygulanamaz. Health check tüm endpointleri sürekli izler. Ayrıca Health check CloudWatch servisi ile entegredir. Yaklaşık 15 tane Health checker ürekli end pointleri takip eder. Health ve Unhealty threshold değeri 3, interval 30 saniye, HTTP, HTTPs ve TCP protokollerini kapsayacak şekilde ayarlanmıştır. Health check'lerin üzerinde bir parent health check tanımlayabilirsiniz. parent HC 256 taneye kadar child HC'i monitor edebilir ve aralarındaki ilişkiyi OR, AND veya NOT olarak ayarlayabilirsiniz.

Eğer health checker %18'den fazla healthy alırsa kaynak sağlıklı kabul edilir. Health checker'lar için gelen trafiğe izin verilmiş olunması gerekir. Private kaynaklar için health check uygulayamadığımız için bu işi cloudWatch alarm ile sağlayabiliriz. Konsola geçelim left hand menüden Health checks'i seçelim. Create health check ile her ec2 için ayrı HC oluşturalım.

IP ile sağlık kontrolü yapacağız. 80 portunu kullanacak ve root sayfası içinde yapacak. İleri ayarlarla interval aralıklarını, threshold sayılarını vb. ayaları özelleştirebiliriz. Sonraki sayfada create alarm seçeneğini no olarak bıraktık. bir süre bekledikten sonra statuslerini healty olarak görebiliriz. Ben eu-central-1 region'undaki ec2 nun security grubunu 80 portuna kapatacağım ve un healty olmasını bekleyeceğim.

Şimdi de parent health check oluşturup diğer HC'leri kontrol etmesini sağlayabiliriz. Bu şekilde or ile herhangi biri veya and ile tümün veyahut da herhangi sayı kadar healty durumunu ayarlayabiliriz.

Monitor olarak ip değil de bu kez diğer HC'leri yapmasını istedim. AND ile hepsi sağlıklı ise parent HC sağlıklı kabul edilsin diye ayarladım.

eu-central-1 unhealty olduğu için ve AND kulladığım için parent HC de unhealty verdi.

d- Routing Policy - Failover

Bu senaryoda iki kaynağımız var. Birincisi Primary, diğeri ise Secondary. Primary instance Health check ile kontrol ediliyor, sonuç healty ise istek primary instance'a yönlendirilir, eğer fail alınırsa istek Secondary instance'a gidiyor. Secondary için health check yapılabilir optional'dır. Şimdi konsola gidelim ve uygulamasını yapalım. failover.devopsandclouds.com kayıt adıyla 2 adet kayıt yapacağım. Policy tipi failover seçeceğim. İlk kayıt için us-east-1 ec2 olacak, ayrıca primary ve health check enable seçeceğim. Diğer kayıt için eu-central-1 ec2 olacak ve sadece secondary seçeceğim.

Sağlık kontrolü başarılı olduğu için us-east-1 daki ec2 dan istek cevaplandı. Bu kez de us-east-1 daki ec2'yu stop edelim o şekilde HC fail verdirelim. Bir süre bekledikten sonra HC menüsünü kontrol edelim ve sayfayı yenileyelim.

Unhealty olduktan sonra trafik eu-central-1'a yönlendirildi.

e- Routing Policy - Geolocation

Latency-based policy'e benzerdir ama kullanımı daha farklı olabilir. Diyelim sizin bir web isteniz var ve belirlediğiniz ülkelerde kendi dillerinde isteklere cevap veriyor. Yani Almanya'dan gelen trafiklere Almanya'da bulunan server cevap veriyor, Amerika'dan gelen isteklere farklı bir server cevap veriyor. Bu arada server aynı ülkede olmak zorunda değil hepsi aynı yerde de olabilir ama içerikleri farklı. Bu senaryoda siz kullanıcıların bölgelerini ülke veya kıta olarak seçebileceksiniz. Burada ayrıca belirlenen yerler harici istek gelirse diye default kayıt yaratmak gerekiyor. Konsola geçelim geo.devopsandclouds.com ismiyle 3 kayıt yaratacağım. Tip olarak hepsinde Geolocation seçeceğim. Avrupa kıtası için eu-central-1 dönüş yapsın, Amerika için us-east-1, geri kalan tüm yerler için us-east-2 cevap versin şeklinde kayıtları gireceğim. Takiben ben Türkiye'den istek göndereceğim ve Avrupa'daki ec2'dan cevap bekleyeceğim.

Yukarıda istediğimiz sonucu almış olduk. Diğerlerini VPN kullanarak deneyebilirsiniz.

f- Routing Policy - Geoproximity

Bu modelde trafik kullanıcıların bulunduğu bölgeye ve kaynakların bulunduğu bölgeye göre yönlendirilir. Bias değeri sayesinde trafiğin yoğunluk oranlarını değiştirebilirsiniz. Bias değeri (1 to 99) arasında ise kaynaklar fazla trafik, (-1 to -99) arasında ise az trafik yönlendirilir. Diğer bir özelliği kaynaklar AWS dışında da olabilir. Koordinatları belirli on-premise kaynakları da kullanabilirsiniz. Bu modeli kullanabilmek için Traffic Flow kullanmak gereklidir.

Traffic Flow sayesinde çok karmaşık policy yapılarını görsel arayüz üzerinden kolayca yapabiliriz. Sol konsoldan Traffic Flow menüsünden Traffic Policy'i açalım ve Create Traffic Policy diyelim. İsim verelim.

Daha önce hazırladığınız bir policy'i import edebilirsiniz. İlk açıldığında start point ile gelir. DNS type'ını seçerek başlayacağız.

Yukarıdaki resimde Geoproximity kural ekledim. Avrupa ve Amerika'da 2 region ekledim. Bias değerleri 0 olduğu için ortadan ikiye ayrılmış şekli sağ tarafta görebiliyoruz. Amerka'daki end point'in bias değerini eksili değerlere düşürdüğümüzde aşağıdaki gibi trafik akışının Avrupa'ya daha fazla yönlendirildiğini görebiliriz.

Create traffic policy diyelim ve 2 noktayı daha gösterip bu modeli bitireceğim. İlk olarak burada versiyonlama yapılabiliyor editlediğiniz zaman versiyon değişir. Geldik en önemli kısma bu hizmetin tabi bir karşılığı var adamlar o kadar uğraşmış aylık 50$ bir ücreti var bizim cürmümüz yetmez deyip burada sonlandıralım 😂

g- Routing Policy - Multi Value

Simple policy'e benzer ama burada health check yapılabiliyor. 8 adete kadar sağlıklı kaynaklarınıza trafiği yönlendirebilme imkanı veriyor.

Burada da health check fail vermesi için farklı bir yöntem izleyeceğim. eu-cental-1 deki EC2'nun HC kontolünü editleyelim ve Advanced configuration ayarlarından Invert health check status tiklediğimizde tam tersine çalışacak. Local bilgisayarımızda terminal açalım ve dig multi.devopsandclouds.com komutunu girdiğimizde hangi bilgisayarlardan dönüş alabildiğimize bakalım.

eu-cental-1 deki 3.127.235.75 'den dönüş alamadık.

Son bir uygulama yapıp konuyu tamamen bitiriyoruz. Bu uygulamada private hosted zone oluşturacağız. Public ve privated hosted zone'lar da aynı isimle kayıt oluşturacağız. Eğer talep VPC içerisinden geliyorsa istek private kaynaklara düşecek, diğer durumda public hosted zone'a istek gelecek. Biraz daha renklendirmek amacıyla public hosted zone için end point'i s3 bucket vereceğim. Hazırlık için web sitesi host edecek şekilde S3 bucket ayarlarını yapalım(Hatırlamak için S3 yazıma bakabilirsiniz). Ayrıca oluşturduğumuz VPC'de de bir linux makine kaldıralım. Bu makinenin içinde apache çalışıp bir sayfa host edecek. Hiç değişiklik yapmanıza gerek yok kendi tanıtım sayfası kalabilir(kendi index.html dosyası kalsın). Ayrıca aynı VPC'de bir adet de windows makine kaldıracağız sadece RDP portu açık olması yeterli. Amacımız windows makine aynı VPC'de olduğu için oradan bir istek gönderdiğimizde apache sayfası açılacak. Kendi local bilgisayarımızdan istek gönderdiğimizde S3 içerisimdeki sayfa cevap verecek. Hazırlıkları yapalım;

Private Hosted zone çalışmamızı da bitirmiş olduk.

Çok yakında http://www.devopsandclouds.com/ adresinden görüşmek üzere yeni web sitemizi yakında hazır hale getireceğiz.

Route53'ün ne işe yaradığını özetleyecek olursak;

Note: Farklı bir domain register'dan domain satın aldıysanız bunu route53'te kullanabilmek için önce public hosted zone oluşturun ve diğer register'ın NS kayıtlarını oluşturduğunuz public hosted Zone'a yapıştırın.